Alex, Thanks very much for what was on KBUGS.TXT when I ftp'd it about 7pm.
I have made changes based on your suggestions, and I shall mail you
the current status of my files. (You'll get two letters, one containing
the "make/take fraction/scaled" and one containing the good stuff.)

I have just modified the beginning of m_log, because I was guilty of the
sin of DOUBLE ROUNDING (of which I warn readers in my books, yet I keep
forgetting). I've also tried to give a better explanation of the
mysterious initialization. Basically, my mistake was in adding 32768 to z;
it's best to think of y and z as a single number, which I was rounding
by adding 4.5 before dividing by 8 (the correct procedure is of course
to add 4.0 and divide by 8).

....

"In the code which defines the octants for use in n_atan, I fail to see
 why the octants must be in {1..8} instead of {0..7} so that
 first_octant would be 0, and you would not need to add first_octant in
 the definitions of the others.  This shouldn't have any effect on the
 code, but I just found it puzzling."

*** True; my first draft had it that way. But these octant codes
are used for many other things in MF, and in all the other applications
they wanted to be positive; hence I made n_atan a little clumsier
to get an overall improvement.

....

I suspect that last digit of n_atan is often wrong. This is not
surprising since it is calculated by summing various elements of
spec_atan each of which is itself an approximation.  Similar comments
apply to n_sin_cos though there the problem is not so evident.

*** I expect the error to be even worse than this (a worst case
occurring when z has been computed as the sum of all the constants
that rounded up, or all those that rounded down). After awhile the
constants are very nearly integers, so the worst case isn't quite
as bad as a person might imagine. But anyway, this much inaccuracy
is tolerable since n_atan isn't made available to a METAFONT user:
The user works in degrees (so I divide by 16 before giving the answer).
PS: As you can expect, I actually add 8 and divide by 16, thereby
being guilty of double rounding if n_atan itself has been
calculated by rounding! But the expected error in n_atan should
be roughly zero...
I think the fact that n_sin_cos is an inverse operation makes the
calculations stable in that case (the errors don't accumulate
at the same digit position).

Thanks again, and expect two more "letters"!